Efforts are being made to more easily conduct business in a web based environment. “Web Services” is loosely understood to mean the ability to discover and conduct business in a web based environment. For example, a user (e.g., a web based application or person with a web browser) may: 1) search through an on line registry of businesses and/or services; 2) find a listing in the registry for web based access to a service that that the user desires to have performed; and then, 3) engage in a web based business relationship with the service application including the passing of relevant information (e.g., pricing, terms and conditions, etc.) over the network.
FIG. 1 shows a generic structure of the web services concept. At the core of a web service is a registry 101 that lists service providers 1021 through 102N who offer their services through a web interface (e.g., businesses that provide specific services, government organizations that provide specific services, internal departments within a private web environment, etc.). Each separate service provider can also be referred to as a web service “publisher” because of its listing in the registry 101.
In practice, a potential user or customer 103 (“a client”) that seeks a service invokes a search through the content of the registry 101. After a suitable service provider is found in the registry 101, the registry 101 forwards to the client 103 instructions on how to access and use the selected service provider's web interface.
Because successful implementation depends upon orchestrated communication and behavior amongst disparate members, a “standard” has evolved that attempts to specify these communications and behaviors. This standard, entitled Universal Discovery, Description and Integration (UDDI), defines provisions for a universal registry 101 containing white pages (contact information), yellow pages (industry classification) and green pages (description of services).
The registry 101 itself is implemented as a distributed network of servers that exchange updated registration information. The UDDI specification also defines a collection of XML based SOAP protocol messages that the different participants (service providers, the registry, clients. etc) exchange amongst each other as appropriate.
A problem, however, is that the UDDI model allows clients to behave largely as anonymous entities. That is, the registry 101 does not require a client 103 to identify himself/herself/itself in order to use the registry's resources. In some cases, the UDDI registry may ask a client if the client wishes to receive future notices and/or other information from a service provider (thereby requiring the client to provide self identifying information). But presently, clients are not required by the UDDI registry as a general rule to submit any self-identifying information as a condition for using the registry or the services of its published service providers.
As such, typically, little (if anything) is known about a client prior to that client's being provided with access and use information for a particular service by the registry. Because many business relationships require a need for knowing the customer/client in some detail, at a minimum, the current UDDI specification either cannot support certain business relationships; or, forces the service providers' themselves to design functional logic that requires a client to unveil himself/herself/itself before a business relationship is entertained.